PERSONAL PROFILE SHARING AND MANAGEMENT 
FOR SHORT-RANGE WIRELESS TERMINALS 

Inventors: T. Heinonen, T. M. Laitinen, S. Bouet, and Sany Zakharia 

FIELD OF THE INVENTION : 

The invention relates to short-range wireless communication systems, network 
and methods of operation. More particularly, the invention relates to personal profile sharing and 
management for ad hoc networks in short-range wireless communication systems using the 
Bluetooth Standard. 

n BACKGROUND OF THE INVENTION 

iQ An ad hoc network is a short-range wireless system composed primarily of mobile 

iU 

^" wireless devices which associate together for a relatively short time to carry out a common 
bi 



purpose. A temporary network such as this is called a "piconet" in the Bluetooth Standard, an 
"independent basic service set" (IBSS) in the EEEE 802.11 Wireless LAN Standard, a "subnet" in 



a 

fU 

ru 

the HIPERLAN Standard, and generally a radio cell or a "micro-cell" in other wireless LAN 

Q 

fM technologies. Ad hoc networks have the common property of being an arbitrary collection of 



wireless devices which are physically close enough to be able to communicate and which are 
exchanging informadon on a regular basis. The networks can be constructed quickly and without 
much planning. Members of the ad hoc network join and leave as they move into and out of the 
range of each other. Most ad hoc networks operate over unlicensed radio frequencies at speeds 
of from one to fifty-four Mbps using carrier sense protocols to share the radio spectrum. The 
distance over which they can communicate ranges from ten meters for Bluetooth ad hoc networks 
to over one hundred meters for wireless LAN micro-cells in an open environment, ad hoc 
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networks consist primarily of mobile wireless devices, but can also include one or more access 
points which are stationary wireless devices, operating as a stand-alone server or connected as 
gateways to other networks. 

Bluetooth is a short-range radio network, originally intended as a cable 
replacement. It can be used to create ad hoc networks of up to eight devices operating together. 
The Bluetooth Special Interest Group, Specification Of The Bluetooth System , Volumes I and 2, 
Core and Profiles: Version 1.1, February 22, 2001, describes the principles of Bluetooth device 
operation and communication protocols. The devices operate in the 2.4 GHz radio band reserved 
for general use by Industrial, Scientific, and Medical (ISM) applications. Bluetooth devices are 
designed to find other Bluetooth devices within their ten-meter radio communications range and 
to discover what services they offer, using a service discovery protocol (SDP). The SDP 
searching function relies on links being established between the requesting Bluetooth device in a 
client role and the responding Bluetooth device in a server role. Once a link has been 
established, it can be used to find out about services in the responding Bluetooth device and how 
to connect to them. 

Other wireless standards support ad hoc networks in addition to the Bluetooth 
standard, the IEEE 802.11 Wireless LAN standard, and the HIPERLAN standard. Examples 
include the IEEE 802.15 Wireless Personal Area Network (WPAN) standard, the Infrared Data 
Association (IrDA) standard, the Digital Enhanced Cordless Telecommunications (DECT) 
standard, the Shared Wireless Access Protocol (SWAP) standard, the Japanese 3rd Generation 
(3G) wireless standard, and the Multimedia Mobile Access Communication (MMAC) Systems 
standard of the Japanese Association of Radio Industries and Businesses. 
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Bluetooth units have general behaviors through which they communicate with 
other units. These behaviors are called "application profiles". There are 13 application profiles 
described in Version 1.1 of the specification, including the Generic Access Profile (GAP), 
Service Discovery Profile (SDP), Generic Object Exchange Profile (GOEP), and Object Push 
Profile. 

The Generic Access Profile (GAP) defines how two Bluetooth units discover and 
establish a connection with each other. The service discovery protocol (SDP) defines the 
investigation of services available to a Bluetooth unit from other units. Generic Object Exchange 
Profile (GOEP) describes defines the set of protocols and procedures used by applications in 
handling object exchanges, e.g. File Transfer Synchronization using the Object Exchange 
(OBEX) Standard. The OBEX Standard is specified by the Infrared Data Association (IrDA), 
Object Exchange Protocol, Version 1.2. The OBEX Standard was adopted by Bluetooth as a 
binary HTTP protocol that allows multiple request/response exchanges. The Bluetooth Object 
Push Profile specification discusses the application of exchanging virtual business cards using 
the OBEX Standard. 

Personal profiles are different from the official set of thirteen Bluetooth 
application profiles. Personal profiles are data sets intended to be exchanged between wireless 
mobile devices. Personal profiles provide information describing a user and his/her device to 
inform other users about the functionality and communication features of the user's device, and to 
inform about the characteristics and interests of the user. Currently, personal profiles are created 
by a user and sent to centralized servers operated by service providers for management and 
access by other users. What is needed is a mechanism or technique enabling a user to personalize 
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his/her mobile, wireless terminal in real time to change and manage the personalization 
parameters at the terminal for sharing with other devices, such as in an ad hoc network. 

Prior art related to personal profiles includes EP 1 130 869 Al entitled 
"Management of User Profile Data" by D. Mandata, published September 5, 2001, filed March 1, 
2000. This reference discloses an Instant Message Broker (1MB) System to allow messages to be 
sent in near real time between users. 1MB is a distributed processing system that integrates 
network technologies, such as IP and Mobil Telecomm networks, allowing users to access 
functionality, accomplish tasks and deliver process information to called parties. 1MB includes a 
database for storing and managing user profile data, which represents sets of user information/or 
user preferences concerning the terminal device users have access to within information 
transmission. The database comprises for each user at least one customizable user profile, which 
can be created, edited and/deleted by the user. Each customizable user profile is associated with 
an environment of the user representing a physical location and/or a logical context of the user. 
The database comprises a plurality of user profiles for one user, wherein only one user profile of 
a user is active at the same time. Each subscriber can have a plurality of user profiles in a so- 
called user space which is a subscriber's own data space as provisioned within the user profile 
database. Users can define different context for different situations and dynamically switch 
between them. The currently used active context describes how the subscriber can be reached. 
The description includes an indication whether the user is currently on-line on a preferred 
terminal device. In addition, a set of alternative terminal devices is provided where the 1MB 
subscriber may be contacted or not reachable at the preferred device. The alternative terminal 
devices can also be used for receiving additional copies of instant messages. 
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The prior art does not describe or suggest a wireless, mobile terminal containing 
personalized user profiles that are installed, edited by and managed by the user on the user's 
mobile terminal. An example of a need for this capability is the real time modification of a sales 
representative's virtual business card to match the perceived interests of a potential customer. 
Currently, the sales representative cannot add or update the information in real time to his/her 
virtual business card. Another example of a need for this capability is in a dating/match-making 
scenario. During a chance meeting involving the exchange of virtual business cards, the user 
may wish to modify his/her personal interest information in real time, to match the perceived 
interests of the other user. 

Still further, the prior art does not describe or suggest uploading the personalized 
user profiles from the user's wireless, mobile terminal to a server operated by service provider, 
for access by the user to update the profiles, and then return them to the user's wireless device. 

SUMMARY OF INVENTION 

To overcome limitations in the prior art described above, and to overcome other 
limitations that will be apparent upon reading and understanding the present specification, the 
present invention is directed to provide a method and an apparatus for sharing a user's Personal 
profile. A user's Personal profile is installed in a service discovery protocol (SDP) database of 
the user's Bluetooth mobile terminal, for sharing with inquiring Bluetooth mobile terminals in an 
ad hoc network. Changes to the Personal profile need only be entered once at the user's terminal. 
The user's Personal profile may be accessed by inquiring Bluetooth terminals when the user's 
terminal has its personal profile response state set to "ON". A standardized form of the user's 
Personal profile is built into the SDP records. The Personal profile includes a list of user 

interests defined by a plurality of fields, each field including a series of attributes, where each 
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attribute is defined by a name, a type, and a value. Every specified interest of the user's has its 
own bit mask. The full complement of personalization data may be stored in one SDP record, 
provided that not too many attributesA>it masks are allocated in the record. Attributes/bit masks 
are allocated in the record using semicolons to separate names, types and values (e.g., NAME; 
STRING; Tomi Heinonen; AGE; INT; 33...) The user's mobile terminal provides processes for 
handling messages and personal profiles and also processes for filtering incoming messages. An 
index screen in the user's terminal enables the user to access a process screen for editing and 
removing keywords related to the processes. The editing and updating of Personal Profiles can 
be performed using the user interface of user's mobile terminal. 

In an alternate embodiment, to accommodate a limited screen size in the user's 
mobile terminal, the editing of the Personal profiles and message filters may be made easier by 
performing that operation on a desktop computer. The Personal profiles can be uploaded via the 
Web and stored at a centralized database, enabling editing on the user's desktop computer. The 
updated Personal profiles can then be downloaded to the user's mobile terminal. The Personal 
profile updates may then be synchronized with the terminal profiles. 

If the responding user's terminal has its personal profile response state set to 
"ON", then an inquiring terminal can make an SDP inquiry to request a Personal profile. The 
SDP inquiry accesses the responding user's terminal SDP database, which is divided into a phone 
book section containing the users personal profile and a more detailed data section for detailed 
personal information. The phone book section can contain "generic" information, e.g. name, 
gender, age, contact information, etc. The more detailed data section can include detailed 
personal profile information, such as sports interests, hobby interests, and so on. The responding 

user's terminal responds in an SDP transaction to provide a standardized format for the requested 
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information. Additional references can also be included in the response, providing links to 

additional user defined information. If the inquiring terminal or client desires the additional user 

defined information, the inquiring client can retrieve the information from the SDP database in 

an object exchange (OBEX) transaction. In response, the inquiring client receives the user 

information from the user's phonebook. Typically, the user's phonebook is encoded in a format 

such as the vCard electronic business card format. The inquiring client also receives user defined 

Personal profiles encoded in extended markup language (XML), 

In one aspect, whenever the user of the wireless terminal wants to provide his/her 

personal profile information to inquiring devices, the user sets the personal profile response state 

Q to "ON". This causes the user's wireless device to write into the class-of -device (CoD) field of 
CO 

W its inquiry response packet, its status as having its personal profile available. The user's wireless 
M 

W terminal can be set by its user to indicate in its class-of-device (CoD) field of its inquiry response 

~ packet, that particular types of personal profile information are available, such as dating/match- 
fjj 

fU making information. The inquiring device can be programmed by its user to recognize that 

□ particular class-of-device (CoD) and respond by browsing or searching the SDP service records 

ru 

of the user's wireless terminal. 

The user's terminal, itself, may run SDP inquires to find other terminals 
supporting Personal profiles. When a connection is formed between the terminals, various 
services can be provided, including personalized, location dependent services, dating services, 
and the identification of profiles that match user defined criteria. 

A feature of the invention is creating, editing and storing personal profiles of a 
user in a wireless, mobile terminal for sharing with other terminals in an ad hoc network in a 

short-range communication system. 
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Another feature of the invention is storing all personal profiles of a user in a 
single Service Discovery Protocol (SDP) record, the record containing contact information, 
standard format profiles of the user's interests, and user or manufacturer defined information. 

Still another feature of the invention is uploading personal profiles from the user's 
mobile terminal and storing them at a service provider's server that is accessible from a desktop 
computer, to enable the user to conveniently edit and update the profiles using the desktop 
computer, and then to return the updated personal profiles to the user's mobile terminal. 

In an alternate embodiment of the intention, a push-mode enables the user's 
terminal to broadcast user profile information, 
p In another alternate embodiment of the intention, the user's short-range wireless 

m 

{d terminal can share information in its personal profile with the inquiring wireless terminal, if their 
lU respective user profiles match within a predefined tolerance. 



ru 



In another alternate embodiment of the intention, the user's short-range wireless 
terminal can share the general information portion of his/her local user profile with another short- 



□ 

ru 
ru 

Q range wireless terminal, if their respective user profiles have a first level of close matching. If 



their respective user profiles have a second level of closer matching, the two terminals can 
further share more detailed information in their respective user profiles. 

In another alternate embodiment of the invention, a server can provide 
matchmaking services via Bluetooth links by registering users of devices. Registration can 
include checking user qualifications for matchmaking, such as being above a certain age. Then, 
when the two respective registered users try to exchange privacy sensitive information without 
having to actually engaged in a conversation with each other, they link to the server, which 
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delivers the same PIN to both devices, thereby enabling the Bluetooth Authentication procedure 



to run automatically in the background for both devices. 



DESCRIPTION OF THE DRAWINGS 



The invention will be further understood from the followed description of a 



preferred embodiment taken in conjunction with the appended drawings. 

Figure 1 is a representation of a user terminal or wireless device in an ad hoc 



network, incorporating the principles of the present invention. 
1^ Figure 2 is a representation of one embodiment of an internal architecture for the 

b 

C3 user terminal of Figure 1 . 

m 

W Figure 3 A is a representation of a typical user personal profile formatted in a bit 

hA 

y mask, as one embodiment, in the user's terminal 101 of Figure 1. 
"p 

p Figure 3B is a detailed representation of the user personal profile of Figure 3 A for 

fu 

fU the user's terminal 101 of Figure 1. The terminal screens 302, 311, 317, 319 show the display 
^4 

Q on the user's terminal 101, of the profile items and categories. 
fU 

Figure 4A is a representation of a text-encoded vCard format available in the 



contact information part 301 of Table A. 

Figure 4B is a representation of an XML encoded non-standard profile available 



in the SDP record of Table A. 



Figure 5 describes a method for creating and editing personal profiles, according 
to one embodiment of the present invention. 
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Figure 6 describes a method for filling out profiles of Figure 3A for entry in the 
SDP records of Table A. 

Figure 7 describes a method for accessing a personal profile of the user terminal 
with user profile support in the ad hoc network of Figure 1. 

Figure 8 describes an alternative embodiment for storing user profiles outside the 
user's mobile terminal 900. 

Figure 9 is a network process diagram of an embodiment of the invention using 
profile push and profile comparison between two Bluetooth devices. 

Figure 10 is a network process diagram of the embodiment of Figure 9, adding 

*| authentication between the two Bluetooth devices. 
CO 

W DESCRIPTION OF PREFERRED EMBODIMENT 

U In the following description of the various embodiments, reference is made to the 

p accompanying drawings which form a part hereof, and in which is shown by way of illustration 
fU 

fjj various embodiments in which the invention may be practiced. It is to be understood that other 

C3 embodiments may be utilized and structural and functional modifications may be made without 

ru 

departing from the scope of the present invention. 

Figure 1 discloses a system 100, which provides personal profile sharing for 
wireless, mobile terminals in ad hoc networks. A user's terminal 101, typically a Bluetooth 
device, includes a memory 103 storing a browser 105, an operating system (not shown), a profile 
editor and manager 108, and a personal profile 107 indicating the user's interests or receiving 
queries from other terminals in an ad hoc network 109. The user's terminal 101 includes a 
display, a keypad 1 13 and an antenna 1 15 for sending and receiving signals 1 17 to other 

Bluetooth devices 1 19, 121 and 123 in a short-range communication system. Antenna 115 also 
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sends and receives signals 117' with an access point 125 linked to by a network 127, e.g. the 
Internet, to a personal data server 129 operated by a service provider. The following description 
is provided for the terminals or wireless devices in the system 100 implemented as Bluetooth 

devices. However, the terminals or wireless devices in the system 100 can also be implemented 
in other wireless standards such as the EEEE 802.1 1 Wireless LAN standard and the HIPERLAN 
standard. 

A connection between two Bluetooth devices is initiated by an inquiring device 
sending out an inquiry message containing an inquiry access code (lAC), searching for other 
devices in its vicinity. Any other Bluetooth device that is listening for an inquiry message 
containing the same inquiry access code (lAC), by means of conducting an inquiry scan, will 
recognize the inquiry message and respond. The inquiry response is a message packet containing 
the responding device's Bluetooth Device Address (BD_ADDR). A Bluetooth device address is 
a unique, 48-bit IEEE address, which is electronically engraved into each Bluetooth device. 

The inquiring device uses the information provided in the inquiry response packet, 
to prepare and send a paging message to the responding device. To establish a connection, the 
inquiring device must enter the page state. In the page state, the inquiring device will transmit 
initial paging messages to the responding device using the device access code and timing 
information acquired from the inquiry response packet. The responding device must be in the 
page scan state to allow the inquiring device to connect with it. Once in the page scan state, the 
responding device will acknowledge the initial paging messages and the inquiring device will 
send a paging packet, which provides the clock timing and access code of the inquiring device to 
the responding device. The responding device responds with a page acknowledgment packet. 

This enables the two devices to form a connection and both devices transition into the connection 
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state. The inquiring device that has initiated the connection assumes the role of a master device 
and the responding device assumes the role of a slave device in a new ad hoc network. 

Each ad hoc network has one master device and up to seven active slave devices. 
All communication is directed between the master device and each respective slave device. The 
master initiates an exchange of data and the slave responds to the master. When two slave 
devices are to communicate with each other, they must do so through the master device. The 
master device maintains the ad hoc network's network clock and controls when each slave device 
can conmiunicate with the master device. Members of the ad hoc network join and leave as they 
move into and out of the range of the master device. Ad hoc networks support distributed 
activities, such as collaborative work projects, collaborative games, multi-user gateways to the 
Internet, and the like. A user's device that joins a particular ad hoc network, does so to enable its 
user to participate in the currently running coUaboradve acdvity. 

Figure 2 discloses one embodiment of the user's terminal 101. Included in the 
terminal 101 is a display 201 for displaying messages received from the access point 127 and the 
other terminals 119, ... 123 in a piconet, e.g. the ad hoc network 109, where the terminal 1 19 may 
serve as an inquiring device. An input device 203 such as the key pad 113, enables the user to 
enter data for transmission to the access point or other terminals. Input device 203 enables the 
user to input changes to the user's personal profiles stored in a storage area 205, including phone 
book information 207, Service Discovery Database 209, and a Personal profile database 211. A 
CPU 213 is connected to both the input 203, the storage devices 205, and to a memory 215 
containing an operating system (not shown) and protocol for the Bluetooth connection/ 
disconnection processes described above. A short-range transceiver 217 is linked to the antenna 
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1 15 for sending and receiving signals to the devices 1 19, 121 and 123 and to the access point 
125. 

In the ad hoc network 109 of Figure 1, the inquiring device 119 sends inquiries to 
other Bluetooth devices in the area, such as the user's terminal 101. The inquiring device 119 
periodically transmits inquiry packets. The general inquiry access code (GIAC) of the packet is 
recognized by all Bluetooth devices as an inquiry message. During the inquiry procedure, any 
other Bluetooth devices that are in the inquiry scan state, such as the user's terminal 101, are 
scanning for the receipt of inquiry packets. If the user's terminal 101 in the inquiry scan state 
receives the inquiry packet with a matching lAC, it will respond with an inquiry response packet 
that has sufficient information to enable the inquiring device 1 19 to build its inquiry response 
table of essential information required to make a connection. Any Bluetooth device recognizing 
the inquiry packet can respond. The inquiring device 119 can now initiate a connection with the 
user's terminal 101. The inquiring device 1 19 uses the information provided in the inquiry 
response packet, to prepare and send a paging message to the user's terminal 101. To establish a 
connection, the inquiring device 1 19 must enter the page state, where it will transmit paging 
messages to the user's terminal 101 using the access code and timing information acquired from 
the inquiry response packet. The user's terminal 101 must be in the page scan state to allow the 
inquiring device 1 19 to connect with it. Once in the page scan state, the user's terminal 101 will 
• acknowledge the paging messages and the inquiring device 119 will send a paging packet, which 
provides the clock timing and access code of the inquiring device 119 to the user's terminal 101. 
The user's terminal 101 responds with a page acknowledgment packet. This enables the two 
devices to form an asynchronous connection-less (ACL) link and both devices transition into the 
connection state. 
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can be browsed. The inquiring device 1 19 can begin by examining the public browse root, and 



The inquiring device 119 can then send to the user's terminal 101, a Service 
Discovery Protocol (SDP) search request packet. The SDP Request packet carries the SDP 
Service Search Attribute Request which includes a service search pattern and an attribute ID list. 
The service search pattern is the description of the pattern for the user's terminal 101 to match in 
the service registry of its SDP database 209. If the user's terminal 101 has the service requested, 
it responds with the service's handle. The service handle identifies the service for which the 
attributes are being requested. The attribute ED list identifies the attributes that the inquiring 
device 119 is requesting. 

The SDP service registry in the SDP database 209 stores service records in a 

Id 

?3 browsing hierarchy. The service records are arranged into a hierarchy structured as a tree that 

a 

CO 

w 

ig then follow the hierarchy out to service classes which are the branches of the tree, and from there 

g to the leaf nodes, where individual services are described in service records. To browse service 
Q 

fU classes or to get specific information about a service, the inquiring device 1 19 and the user's 
fU 

terminal 101 exchange messages carried in SDP packets. There are two types of SDP packets, 
the SDP Service Search Attribute Request packet and the SDP Service Search Attribute 
Response packet. The SDP Request packet carries the SDP Service Search Attribute Request, 
which includes a service search pattern and an attribute ID list. The service search pattern is the 
description of the pattern for the user's terminal 101 to match in its SDP service registry in the 
database 209. If the user's terminal 101 has the service requested, it responds with the service's 
handle. The service handle identifies the service for which the attributes are being requested. 
The attribute ID list identifies the attributes that the inquiring device 1 19 is requesting. The SDP 

response packet returned by the user's terminal 101 carries the SDP Service Search Attribute 
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Response which includes a service record handle list and the attributes. The service record 

handle list and the attributes are then examined by the inquiring device 1 19. 

As described above, an inquiry response packet from the user's wireless terminal 

101, has sufficient information to enable the inquiring device 119 to build an inquiry response 

table of essential information required to make a connection. The Bluetooth frequency hop 

synchronization (FHS) packet structure for an inquiry response packet sent by the user's wireless 

terminal 101, includes a class-of-device (CoD) field. In one aspect of the invention, whenever the 

user of the wireless terminal 101 wants to provide his/her personal profile information to 

inquiring devices, the user sets the personal profile response state to "ON". This causes the user's 

J| wireless device 101 to write into the class-of-device (CoD) field of its inquiry response packet, 
CO 

y its Status as having its personal profile available. 

j^g The inquiring device 119 constructs the inquiry response table with the 



5 

C3 

ry 
ru 

ru 



information in the inquiry response packets received from responding devices, such as the user's 
wireless terminal 101. The inquiry response table shows the essential information gathered by the 
link controller in the inquiring device 1 19, which is needed to make a connection with any of the 
responding wireless devices. In this aspect of the invention, any responding devices are flagged, 
such as the user's wireless terminal 101, that have a class-of-device (CoD) field with the status of 
having its personal profile available. 

There are several options that can be programmed in the inquiring device 119, for 
processing the data gathered in the inquiry response table. The inquiring device 1 19 can be 
programmed to determine whether the class-of-device (CoD) field for a responding device has 
the status of having its personal profile available. If so, then the inquiring device 119 can browse 

or search the SDP service records of the user's wireless terminal 101, since it is now known that 
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they have personal profile information available. Since an analysis of the class-of-device (CoD) 
field only requires the receipt of an inquiry response packet, and does not require the completion 
of a connection between the two devices, this option provides a quick search of responding 
devices. The inquiring device 1 19 can provide to its user a "QUICK SEARCH" option in its 
initial logon menu, which can invoke the process to check the data gathered in the inquiry 
response table to determine whether the class-of-device (CoD) field for any responding device 
has the status of having its personal profile available. This implementation is optional. 

The inquiring device 119 can be programmed to determine whether the class-of- 
device (CoD) field for a responding device, such as the user's wireless terminal 101, has a 
specific type of personal profile information specified in the class-of-device (CoD) field. The 
inquiring device 119 can match it with an entry in a search opdons list table in the inquiring 
device 119. For example, the user's wireless terminal 101 can be set by its user to indicate in its 
class-of-device (CoD) field of its inquiry response packet, that a dating/match-making personal 
profile is available. The inquiring device 1 19 can be programmed by its user to recognize that 
particular class-of-device (CoD) and respond by browsing or searching the SDP service records 
of the user's wireless terminal 101. The inquiring device 119 can be programmed for optional 
special processing of the SDP service records with dating/match-making personal profile 
information from the user's wireless terminal 101. 

Figure 3A is an overview of a typical user profile 300 stored in memory 215 
(Figure 2) as a record and including contact information 301 having a pointer to an entry in the 
phonebook 207 (Figure 2) for responding to queries from another user in the ad hoc network. 
The profile 300 further includes a standardized profile part 304 defining the user's personal 

information, interest and other matters, as will be described in more detail in connection with 
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Figure 3B. In one embodiment, the record may include a plurality of "bit masks" 306^ . . .306'^, 

where the plurality is an integer "N". Each bit mask contains two bytes representing a profile, 

where byte 308 identifies the profile in part 304 and byte 310 enables the user to characterize the 

content of that profile. The profile may be characterized, in one embodiment by identifying the 

qualities of the profile using binary Is (illustrated by filled circles) and binary Os (illustrated by 

empty circles) to indicate yes/no choices, respectively or vice versa. There can be bit mask 

values that are assigned by convention to indicate generic interests such as art, dating, and sports. 

The bit masks 306 can be used to facilitate the user's selection of one profile among many 

profiles that the user has stored in the SDP database 209. The bit masks can also be used to 

C3 facilitate communication with the inquiring device 1 19. The inquiring device 1 19 can retrieve a 
C3 

^ bit mask 306 in an SDP response packet returned by the user's terminal 101. The SDP response 

\^ packet carries the SDP Service Search Attribute Response which includes the bit mask. The bit 

a' mask can then be examined by the inquiring device 1 19, comparing its value with reference bit 
{3 

fU mask values indicating the generic interests. 

ru 

Profile 300 of Figure 3A further includes user and/or manufacturer defined profile 

C3 

part 312 represented by a datastream 3 14, including a user identification field 316 having a 
plurality of 3-part sub-fields 318*, 318^, to 318", where the plurality is an integer "n". Each 
subfield contains a name portion 320 identifying a user or a manufacturer associated with the 
terminal, a format portion 322 defining specific information related to the name or the 
manufacture, and a value portion 324 providing a code representing the specific information 
related to the user or manufacturer. The datastream 314 can be used to facilitate the user's 
selection of one profile among many profiles that the user has stored in the SDP database 209. 

The datastream 314 can also be used to facilitate communication with the inquiring device 1 19. 
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The inquiring device 119 can retrieve a datastream 314 in an SDP response packet returned by 
the user's terminal 101, The SDP response packet carries the SDP Service Search Attribute 
Response which includes the datastream 314. The datastream 314 can then be examined by the 
inquiring device 119. 

Figure 3B shows a more detailed view of the personal profile 300 comprising a 
plurality of sub-profiles. A sub-profile 300^ defines message processing. A sub-profile 300^ 
provides editing of personal profiles related to user information, interests, etc. A sub-profile 300^ 
provides processes for filtering messages received from users on the ad hoc network. Each sub- 
profile includes a list of user interests defined by a plurality of fields, each field including a series 
^3 of attributes, where each attribute is defined by a name, a type and a value. 

The sub-profile 300* in Figure 3B, sorts received messages that are received 
j,y from the ad hoc network or access point into advertisements 303, warnings 305, announcements 
a 307, and personal messages 309. Using the Platform For Interconnect Content Selection (PICS) 
Rules , published at http://www.\v3.org/PICS, a screening program that provides an indicator 



describing the content of each message. The indicator is recognized by the sub-process and 
accepted or rejected according to the user's interest as inputted via a screen 311 in Figure 3B. 
The user clicks on the messages to be rejected and allows the other messages to be processed for 
display to the user. The screen 311 permits the user to change message selections at any time, 
without changing the records in the personal data server 129 (see Figure 1) at anytime, thereby 
enabling the personal profile to be current with the users messages interest. 

A sub-profile 300^ in Figure 3B, enables the user to install and edit user's private 
profile information, including phone book information related to age, gender, profession, contact 

information, picture and other related information that the user wishes to make available to other 
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users in the ad hoc network. Also included in the sub-profile 300^ are the user's interest 315, 
which may be in different categories indicated in a screen 317 in Figure 3B. The categories 
include, for example, Art, Present, Dating, and Sports. Each interest is further expanded in a 
screen 319 in Figure 3B, listing specific interest in a category. 

The sub-profile 300^ in Figure 3B, further includes a shopping list 321 for 
different merchants. A, B, C, D, each list including key words or merchandise in which the user 
has an interest as described in an accompanying sub-screen (not shown). The sub-screen allows 
the user to edit or delete from the contents in the shopping list. 

The sub-profile 300^ in Figure 3B, may also include a digital signature, which can 

C3 be generated by the user in the event that merchandise is ordered and payment is required by the 
C3 

merchandiser. Digital signatures and their protection are described in the text Applied 
[g Cryptography by B Schneier, published by John Wiley & Sons, New York, NY, Part 2.6, ISBN 
0-471—12845-7), 1996 

fU Responsive to screen 302 in Figure 3B, the sub-profile 300° filters user profiles. 

The sub-profile 300" enables the user to establish a state 325 "accepting all messages", or 
alternately a state 327 "rejecting all messages", or alternately a state 329 "filtering all messages". 
This is accomplished using the PICS rules related to user information 313, or using user interests 
315, or using shopping list 321. This provides the ability to allow the user to edit/remove 
keywords filtering the messages. 
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Table A is a representation of user personal profiles formatted in one SDP record, 
including contact information, standard user profiles and user and/or manufacturing profiles 
Table A shows all user profiles formatted in one Service Discovery Protocol (SDP) record 400 
stored in the SDP database 209 (Figure 2). Table A is organized into eight columns labeled "A" 
through "H" and into 25 rows labeled "1" through "25". The record 400 shown in Table A 
includes the contact information part 301 shown in rows 1 and 2, standardized profile part 304 
shown in rows 3 through 12, and user and/or manufacturer defined profile part 312 shown in 
rows 13 through 25. 

The contact information part 301 of Table A includes a vCard string shown in 
Table A at columns E and F, row 2, the contents of which appear in Figure 4A. Figure 4A is a 
representation of a text-encoded vCard format 401 available in the contact information part 301 
of Table A. The contact information part 301 includes the name of the individual, telephone for 
both voice and fax. vCards are an electronic business card for Personal Data Interchange. The 
vCard facilitates various data interchanges including exchanging business cards, Internet mail, 
computer/telephone applications and video and data conferencing. The Card is described in the 
vCard V2.1 specification published by the Internet Mail Consortium at 
http://www.imc.org/pdi/vcardoverview.html. T he Internet Engineering Task force (IETF) has 
released the specification for vCard version 3. The two parts of the definition are: RFC 2425, 
MIME Content-Tvpe for Directory Information and RFC 2426, vCard MIME Directory Profile . 
In the future, other formats may replace the vCard, such as XML formats based on DTDs. 

The standardized profile part 304 of Table A shown in rows 3 through 12, 
includes User ProfilelD lists, such as User ProfilelD # 1 shown in Table A at column B and C, 
row 4, and User ProfilelD # 2 shown in Table A at column B and C, row 7, up to User ProfilelD 
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# n shown in Table A at column B and C, row 10. Each User ProfilelD profile includes a Version 
Number shown in Table A at column C, row 5, a profile filter shown in Table A at column C, 
row 6, a record, e.g. a bit mask shown in Table A at column D, row 6, a UUID shown in Table A 
at column E, row 4, and a bit mask code shown in Table A at column F, row 5, as represented by 
reference 306' in Figure 3 A. 

The User/Manufacturer Defined Profile Part 312 of Table A shown in rows 13 
through 25, includes a plurality of Profile IDs shown in Table A at column B, rows 14, 18, and 
22. The Profile IDs are each identified by a UUID shown in Table A at column E, row 14, and 
including a field name shown in Table A at column C, row 15, a field type shown in Table A at 
column C, row 16 and a field value shown in Table A at column C, row 17 as described in 
conjunction with reference 314 of Figure 3 A, Each field is associated with a Profile Version 
shown in Table A at column D, row 15 defined by a bit string shown in Table A at column E, 
row 15 for the name, a descriptor shown in Table A at column E, row 16 for the format and a 
parameter shown in Table A at column E, row 17, which varies for the value. 

Non-standard profiles 450, as shown in Figure 4B, may be prepared and included 
in the SDP record. Figure 4B is a representation of an XML encoded non-standard profile 
available in the SDP record of Table A. Each non-standard profile may be XML encoded 
defining the Document Type, Element and User Profile Version, which track the information 
content of the standardized profiles 304. The XML program, Version 1.9 is described in the W3C 
recommendation of February 1998. 
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Table B is a representation of the user profiles of Figure 3A, formatted in one 
Service Discovery Protocol (SDP) record in SDP database 209, with pointers to the Phone book 
207 and Profiles database 211. Table B is organized into eight columns labeled "A" through "H" 
5 and into 16 rows labeled "1" through "16". The record 400 shown in Table B includes the 

contact information part 301 shown in rows 1 and 2, standardized profile part 304 shown in rows 
3 through 12, and user and/or manufacturer defined profile part 312 shown in rows 13 through 
16. Table B shows user profiles 400 formatted in one SDP record with pointers to the 
phonebook database 207 and profile database 211 (See Figure 2) in the user's terminal 101. The 
QO contact information part 301 of Table B includes an index shown in Table B at column B, row 2 

9 

W of the vCards in the phone book 313 (Figure 3B). The standard profile's part 304 of Table B 
iU 

y includes a list shown in Table B at column D, row 3 of user profile IDs, as described in Table A. 

If 

g The user and/or manufacturer defined profiles 312 of Table B include an index shown in Table B 
□ 

rU at column D, row 14, list of profile IDs, as described in Table A. A user may use the index 

fU 

shown in Table B at column B, row 2, the list shown in Table B at column D, row 3 and the 

o 

index shown in Table B at column D, row 14, to point to the profile in the SDP database 209 
shown in Fig, 2. 

Figure 5 in conjunction with Figure 2, describes a process 700 for creating and 
editing profiles in the user's mobile terminal 101. In step 701, the process starts and the phone 
20 book database 207 is entered in step 702. A phonebook editing menu (not shown) stored in the 
memory 215, is activated to input the user's contact information in step 703. The contact 
information, in one embodiment, includes age, gender, profession and other details as indicated 
in Figure 3B. A test is made to determine whether the profiles database 21 1 should be entered in 
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step 705. A "no" condition exits the phone book and the editing menu in step 707. A "yes" 

condition activates a profile editing menu (not shown), stored in the memory 215 for preparing a 

standardized profile 400 in step 709 for storing as an OBEX file in the profile database 211. In 

step 711, a profile is chosen to fill out among a number of available profiles related to interest, 

5 shopping lists, etc. In step 713, the process transfers to entry point A in Figure 6 if the user 

wishes to complete the profile. Otherwise, step 721 determines the user interest in completing 

other profiles. A "yes" selection returns the process to step 711 and 713. A "no" selection exits 

the profile-editing menu in step 731 and the process ends in step 733. 

In Figure 6, a test is made in step 715 to determine whether the profile is standard 

^3l0 format or not. A "yes" condition initiates step 717 whereby the profile items and categories are 

[y displayed on the terminal screens 302, 311, 317, 319 and the like described in Figure 3B. The 
H 

y relevant items are selected in step 719 to complete the profile, which is stored as an SDP service 
record in the SDP database 209 or as an OBEX file in the profiles database 21 1. In step 729 the 
user is queried to determine interest in completing other profiles. A "yes" selection transfers the 



ru 

ru 

q15 process to entry point B in Figure 5 for repeat of steps 711 and 713. A "no" selection transfers the 



ru 



process to entry point C in Figure 5, where the profile editing menu is exited in step 731. 

In Figure 6, if the user wishes to enter a non-standard profile in either the SDP 
database 209 or the profile database 211, e.g. a User/Manufacturer Defined Profile 312 (Figure 
3A), step 722 is performed to assign a name to the profile. A name or format assigned is 
20 assigned to the item in step 724 and a value is assigned to the item in step 725. A test 728 is 
performed to determine if additional items are to be defined. A "yes" selection returns the 
process to step 724. A "no" selection transfers the process to step 729 where a "yes" selection 

returns the process to entry point B and steps 71 1, 713 in Figure 5, as previously described in 
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Figure 5. A "no" selection returns the process to entry point C in Figure 5, as previously 



described. 



Figure 7 describes a process 800 for an inquiring Bluetooth terminal or Access 



Point 801, such as the inquiring device 1 19 of Figure 1, to access the personal profile of the 
5 user's Bluetooth Terminal 803, such as the user's wireless terminal 101 of Figure 1, having user 
profile support, using the Bluetooth packet structure and SDP Service Search Request format. In 
step 805, the inquiring terminal 801 transmits a user Bluetooth inquiry 805 and the user 803 
responds with an inquiry response 807. The inquiring terminal 801 sends an SDP inquiry in step 
809 to determine whether the user's terminal support's user personal profiles. In step 811, the 



^3lO user 803 provides an SDP inquiry response indicating that the personal profiles are available, 
fg The inquiring terminal 801 reads all or part of the profiles and submits multiple SDP inquiries, if 
iji necessary, in step 813. The user 803 responds to the SDP inquiries in step 815. The inquiring 



terminal 801 retrieves more detailed contact information profiles, not available to SDP, by means 



ru of an OBEX request 817 using object exchange protocols. Object exchange (OBEX) protocols 



5 are described in the Infrared Data Association, Version 1 .2, PO Box 3883, Walnut Creek, 

California USA 94958. Multiple OBEX requests 817 may be made by the inquiring terminal 801 
and the user 803 provides OBEX responses to the requests in step 819, after which the process 
ends. 



20 user's mobile terminal 850. The profiles may be stored in a user profile server 851 linked to the 
desktop computer or laptop 853 via Internet 855. The user may use the desktop computer or 
laptop 853 to create, edit and alter profiles in the profile server. The user's mobile terminal 850 

has access to the profile server 851, via a Wireless Application Protocol (WAP) gateway 857, 

Case 28580 (4208-4064) 26 
31897 v2 




Figure 8 describes an alternative embodiment for storing user profiles outside the 



serving a cellular telephone network 861 to which the mobile terminal 850 has access. The 
gateway implements the Wireless Application Protocol supported by and available from the 
WAP Forum. Any Bluetooth inquiries for personal profiles can be sent to the user profile server 
851, via the WAP gateway linked to the Internet for accessing the user profile server. The 
profiles are downloaded to the user's mobile terminal 850 for response to inquiries from other 
terminals in an ad hoc network. Storing the personal profiles in the server 851 reduces the 
storage load on the phone book, SDP, and profile databases in the user's mobile terminal shown 
in Figure 2. 

The resulting invention enables the user of a wireless, mobile terminal to install a 
personalized user profile in his/her terminal and to update that profile in real time. For example, 
the invention enables a sales representative to update his/her virtual business card in real time to 
match the perceived interests of a potential customer. As another example in a dating/match- 
making scenario, during a chance meeting involving the exchange of virtual business cards, the 
user may can modify his/her personal interest information in real time, to match the perceived 
interests of the other user. 

In an alternate embodiment of the intention, a push-mode enables the user's 
terminal to broadcast user profile information. Figure 9 is a network process diagram of an 
embodiment of the invention using profile push and profile comparison between two Bluetooth 
devices. Inquiring device 119, user's terminal 101, and wireless device 121 engage in a Bluetooth 
device inquiry stage 905. Then, inquiring device 1 19 sends a profile push message 907 to the 
user's terminal 101. The profile push message 907 contains enough information to characterize 
the profile in inquiring device 1 19 so as to enable user's terminal 101 to compare the similarity 

between the user profiles in the two devices. Such characterizing information can be some 
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limited information about the user or the user's device 119, for example. Such characterizing 

information can be a bit mask, which can be examined by the user's terminal 101 in step 908, 

comparing its value with reference bit mask values indicating any generic interests. In this 

example, user's terminal 101 determines at step 908 that the two user profiles compare 

sufficiently to justify expressing an interest in obtaining more information about the profile of 

inquiring device 119. Then the user's terminal 101 returns a profile response 909, such as "I'm 

interested", to the inquiring device 119. In the meantime, the inquiring device 1 19 sends another 

profile push message 911 to the wireless device 121, similar to message 907. In this example, 

the wireless device 121 determines at step 912 that the two user profiles do not compare Then the 

J^O wireless device 121 returns a profile response 913, such as "Not interested", to the inquiring 

device 1 19. In response to the profile response 909, "I'm interested", sent by the user's terminal 

y 101 to the inquiring device 119, the inquiring device 1 19 prepares to send personal information 

3 in step 914. The inquiring device 1 19 sends a profile message 925 to the user's terminal 101 with 
Q 

the profile information "My Phone Number". 

Figure 10 is a network process diagram of the embodiment of Figure 9, adding 

fU 

authentication between the two Bluetooth devices. Following step 914, the inquiring device 1 19 
sends an authentication request 915 to the user's terminal 101. In step 916. both users input the 
same PIN on their respective devices 101 and 1 19. Then the user's terminal 101 returns an 
authentication response 917 to the inquiring device 1 19. Then, the inquiring device 1 19 sends 
20 the profile message 925 to the user's terminal 101 with the profile information "My Phone 
Number". 
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In another alternate embodiment of the intention, the user's short-range wireless 
terminal can share information in its personal profile with the inquiring wireless terminal, if their 
respective user profiles match within a predefined tolerance. 

In another alternate embodiment of the intention, the user's short-range wireless 
5 terminal can share the general information portion of his/her local user profile with another short- 
range wireless terminal, if their respective user profiles have a first level of close matching. If 
their respective user profiles have a second level of closer matching, the two terminals can 
further share more detailed information in their respective user profiles. 

General information can be transferred in a push model, without authentication of 

Qo the receiving party and even without Bluetooth encryption. However, sending of the more 
C3 

y detailed, private part of the user's profile should be protected by Authentication and Encryption. 

[j For example, before sending the more detailed, private part of the profile, the sending device 

a triggers the exchange of the Bluetooth PIN between the sender and the receiver (if that has not 
C3 

W been done before) to tum on the encryption of the baseband connection. In the same way, and in 

fy 

the case of the Pull model, the Pull request for the more detailed, private part of the profile 
triggers the device owning the profile to request Authentication of the device that issues the Pull 
request. 

Bluetooth Authentication usually requires that the two users exchange the PIN 
outside the channel, such as orally. In some scenarios, this may not desirable. The invention 
20 provides other ways for the two users to share a secret without orally communicating with each 
other. The server 129 in Figure 1 can provide matchmaking via Bluetooth links by registering 
users, such as the users of devices 101 and 119. Registration can include checking user 

qualifications for matchmaking, such as being above a certain age. Then, when the two 
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respective registered users of devices 101 and 1 19 try to exchange privacy sensitive information 
without having to actually engaged in a conversation with each other, they hnk to the server 129, 
which delivers the same PIN to both devices 101 and 1 19, thereby enabling the Bluetooth 
Authentication procedure to run automatically in the background for both devices 101 and 119. 

In addition to the Bluetooth standard, the resulting invention applies to wireless 
standards such as the IEEE 802.1 1 Wireless LAN standard, the HIPERLAN standard, the IEEE 
802.15 Wireless Personal Area Network (WPAN) standard, the Infrared Data Association (IrDA) 
standard, the Digital Enhanced Cordless Teleconrmiunications (DECT) standard, the Shared 
Wireless Access Protocol (SWAP) standard, the Japanese 3rd Generation (3G) wireless standard, 
and the Multimedia Mobile Access Communication (MMAC) Systems standard of the Japanese 
Association of Radio Industries and Businesses. 

While the invention has described in connection with a preferred embodiment, 
various changes can be made without departing from the spirit and scope of the invention. 
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